System and method for automatically populating a dynamic resolution list

ABSTRACT

The system and method of the present invention automatically provides dynamically generated completion information for facilitating user input of email addresses or contact information. This completion information is developed from a “data store” comprised of multiple data sources such as previously sent or received email, and other types of electronic files such as word processor or spreadsheet files. The present invention monitors and uses the information in the data store to automatically store, track, maintain, and organize data entries in a dynamic “resolution list”. As a user begins to input an email address or contact, the present invention can either automatically complete the entry using a most probable result from the resolution list, or can display a list of likely matches from which the user may select the desired email address or contact.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates to a system and method for dynamicallypopulating a resolution list and facilitating user input byautomatically providing generated completion information in real timewith suggested entries of the resolution list.

2. Related Art

Electronic mail (email) has become increasingly popular and is widelyrecognized as a standard form of communication. Typically, email usersrequire an email client for sending and receiving email. Many of theseemail clients contain advanced features and options for the convenienceof the email users. One such feature or option includes automatic emailaddress resolution. In some systems, automatic email resolution isdesigned to automatically locate an email address from a user's manuallycreated email address book. Consequently, when a user initiatescomposition of an email message, the user need only enter initialportions of a recipient's email address or a “friendly name” known to beassociated with the recipient.

Friendly names are used to avoid the impersonal technical format ofemail addresses. The technical format (required by email clients toproperly forward email) of an email address is usually denoted byusername information followed by a connector and then domain oraffiliation information. As an example, the technical format for auser's contact, whose name is Joe William Smith, might be in the form“joes554@hotmail.com” (“joes554” is the username; “@” is the connector;and “hotmail.com” is the domain), while the non-technical format orfriendly name for this email address might simply be “Joe Smith”.Clearly, the technical format is esoteric and harder to remember thanthe friendly name. Also, people sometimes randomly chose usernames, andthese usernames are often not related to the actual name or the nicknamethat he/she is commonly known by. In addition, to complicate matters,many people have similar usernames or share the same or similar domains.As such, email resolution is designed to simplify composition of emailsby allowing a user to find a recipient without requiring the user toknow the recipient's exact and complete email address.

Nevertheless, these systems are limited because resolution of emailaddresses depends on the detailed information or “friendly information”(such as the actual names or nicknames of contacts), provided by theuser for email addresses as well as the email client and its resolutiontechnique. For instance, many email clients resolve email addresses intofriendly names by comparing and verifying the user's “friendlyinformation” entry in the “send to” portion of an email message againstrecipient information previously entered by the user (for example, in anemail address book) and located in the user's email client's database(commonly referred to as “friendly name lookup”) for that particularrecipient. However, many email users do not take the time to enterfriendly name information into their email address books. Thus, thesesystems are limited by the users willingness to update and fullycomplete his/her email address book.

Therefore, what is needed is an email system that not only utilizesemail users' entries, but also other known information that is notdependent on the entries to automatically resolve email addresses.

SUMMARY

To overcome the limitations in the background art described above, andto overcome other limitations that will become apparent upon reading andunderstanding the present specification, the present invention isembodied in a system and method for dynamically populating a resolutionlist and facilitating user input by automatically providing generatedcompletion information in real time with suggested entries of theresolution list. The completion information is associated with theintended user input and can be email addresses or contact information.

The completion information is initially developed from a store of datacomprised of intended user input. For instance, the completioninformation can be previously sent or received email, data embeddedwithin other types of electronic files, from email or other electronicdocuments which may not have been sent or saved to a permanent storagemedium but which contained usable contact data, or from tracking emailaddresses or contacts used by the user when both sending and receivingmessages.

The system and method automatically tracks and maintains entries, suchas contacts or email addresses and organizes and maintains the trackedentries in a dynamic resolution list. As a user begins to input an emailaddress or contact in an input entry area, the system of the presentinvention can either automatically complete the entry using a mostprobable result from the dynamic list, or can display a list of likelymatches from which the user may select the desired email address orcontact. Further, the list may also be accessed via a user interfacethat provides the user with options such as, for example, editing,saving, and exporting the list. As one example, the completioninformation can be presented to the user as an overlaid mini userinterface pane, such as a “pop-up” user interface area. The “pop-up”user interface automatically appears over the current user interface inclose proximity to the input entry area and contains the organizedcompletion information.

In one embodiment, the present invention monitors and uses informationof the store and of other electronic files, whether or not those filesor information have been saved to permanent storage medium, toautomatically and dynamically populate a resolution list with emailaddresses and contact information. Priority is given to the mostrecently used (MRU) email addresses and contacts when populating theresolution list. However, frequency of use and time since the last useof specific email addresses and contacts is also considered in“weighting” the entries in the resolution list. Entries having a higherweight will be chosen before matching entries having a lower weightwhere multiple entries match user input.

The information from the store used to populate the resolution listincludes previously sent and received email addresses and contacts, andemail addresses and contacts that existed on other or older softwareversions that were subsequently upgraded/updated. Email addresses andcontacts from other electronic files, such as for example, wordprocessor or spreadsheet files, may also be used to provide informationto populate the resolution list. However, information that the userspecifically enters when addressing messages, or from mail that the userreceives, whether or not the mail is sent, saved or deleted, ispreferably the primary source of data for the resolution list. Theinformation extracted from the store is preferably used to initiallypopulate the resolution list and to restore the resolution list after a“crash” or other unexpected event occurs that causes the resolution listto be lost. Once the initial resolution list is initially populated, itis dynamically updated with new email address and contact information asthat information enters the data store.

Preferably, the resolution list is constrained as to the maximum numberof entries that would ensure that the user does not notice a lag timewhile the software searches for matches in the resolution list. Becausethe size of the list is preferably constrained, entries of lesser weightwill be replaced with entries of greater weight as the list isdynamically updated. However, in one embodiment, the user may specifythe desired list size. Further, because the list is dynamic, the weightsassigned to individual entries are also dynamic. The weights arecontinuously updated as new information becomes available.

The foregoing and still further features and advantages of the presentinvention as well as a more complete understanding thereof will be madeapparent from a study of the following detailed description of theinvention in connection with the accompanying drawings and appendedclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numbers representcorresponding parts throughout:

FIG. 1 is a block diagram illustrating an apparatus for carrying out theinvention.

FIG. 2 is a general block diagram illustrating an overview of thepresent invention.

FIG. 3 is a flowchart of the general operational features of the presentinvention.

FIG. 4A is a flowchart illustrating one set of rules for initiallypopulating a resolution list in accordance with the present invention.

FIG. 4B is a flowchart illustrating one set of rules for weightingentries in the resolution list of FIG. 4A.

FIG. 4C is a flowchart illustrating one set of rules for updating theproperties of entries in the resolution list of FIG. 4A.

FIG. 4D is a flowchart illustrating the rules for adding or removingentries to or from the resolution list of FIG. 4A.

FIG. 5 is a general block diagram of a user interface in accordance withthe present invention.

FIG. 6 is a sample user interface incorporating the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following description of the invention, reference is made to theaccompanying drawings, which form a part hereof, and in which is shownby way of illustration a specific example in which the invention may bepracticed. It is to be understood that other embodiments may be utilizedand structural changes may be made without departing from the scope ofthe present invention.

Introduction

Although users of many current electronic mail systems (email clients)have the ability to provide the email client with email address data orcontact data, many users do not provide this information. This isbecause, initially, the user is typically required to manually enter thedata in an address book database or contact database for properpopulation of the respective database, which is time consuming andtedious. Also, some users do not know how to populate their address bookdatabase or contact database. Consequently, resolution techniques ofcurrent email clients are limited by their users' willingness toinitially populate their email address book and contact databases.

As a result, without email resolution, a user may inadvertently enter awrong character when composing an email. This creates an incorrect emailaddress and prevents the email from reaching its intended destinationafter the email is sent. Many times this error will not be obvious atthe time the sender sends the email and significant time could passbefore the sender realizes this error. Since one of the primaryadvantages of email includes quick transfer of information, this delayis can be a significant drawback. Further, because many users do notmanually populate their address book, and since human memory isimperfect, it is not uncommon for a user to lose track of, or simplyforget an email address of someone with whom they choose to correspondwith.

The present invention solves these and other problems by providing asystem and method for facilitating user input of email addresses and/orcontact information by automatically providing dynamically generatedcompletion information that is not solely dependent on manual populationof contact data by the user. This completion information is initiallydeveloped from an email store that is comprised of contact data manuallycreated by the user and contact data that is automatically generated.Namely, the email store can be comprised of previously sent or receivedemail, email addresses and contacts that existed on other or older emailclient versions that were subsequently upgraded and/or updated or fromdata embedded within other types of electronic files such as, forexample word processor or spreadsheet files.

The present invention uses information of the email store to initiallypopulate a dynamic “resolution list” with entries, such as emailaddresses or contacts. Following the initial population of theresolution list, the entries are dynamically organized and updated asnew information enters the data store. Specifically, email addresses andcontacts are cached in an in-memory resolution list accessible byaddress resolution code. As a user begins to input an email address orcontact, a system and method according to the present inventionautomatically suggests one or more entries, with the most likely entrypreferably highlighted, by using the most probable results from theresolution list. The user may then pick the appropriate data.Additionally, the user is preferably allowed to continue to enter datawhen the completion information does not match the address or contactintended by the user.

Entries in the user's “address book” (which may or may not be populated)may also be used to generate completion information. However, entriesexisting in the address book are preferably not added to the resolutionlist. Further, if an entry that is added to the address book matches anentry in the resolution list, the matching entry in the resolution listis preferably removed from the list.

When populating the resolution list, priority is given to the mostrecently used (MRU) email addresses and contacts. However, the frequencyof use and the time since last sending to, or receiving from, specificemail addresses and contacts are also considered in “weighting” theentries in the resolution list. Entries having a higher weight will beprovided before matching entries having a lower weight where multipleentries match user input. Further, where multiple entries of varyingweights match user input, the user, if desired, may choose from thevarious entries via a user interface.

Preferably, the resolution list is constrained as to the maximum numberof entries to ensure that the user does not notice a lag time while thesoftware searches for matches in the resolution list. However, in oneembodiment, the user may modify the size of the resolution list via theuser interface. Because the size of the list is preferably constrained,entries of lesser weight will be replaced with entries of greater weightas a full list is dynamically updated. Further, because the list isdynamic, the weights assigned to individual entries are also dynamic.These weights are continuously updated as new information becomesavailable.

Exemplary Operating Environment

FIG. 1 and the following discussion are intended to provide a brief,general description of a suitable computing environment in which theinvention may be implemented. Although not required, the invention willbe described in the general context of computer-executable instructions,such as program modules, being executed by a personal computer.Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types. Moreover, those skilled in theart will appreciate that the invention may be practiced with othercomputer system configurations, including hand-held devices,multiprocessor systems, microprocessor-based or programmable consumerelectronics, network PCs, minicomputers, mainframe computers, and thelike. The invention may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules may be located on both local and remotememory storage devices.

With reference to FIG. 1, an exemplary system for implementing theinvention includes a general-purpose computing device in the form of aconventional personal computer 100, including a processing unit 102, asystem memory 104, and a system bus 106 that couples various systemcomponents including the system memory 104 to the processing unit 102.The system bus 106 may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. The system memoryincludes read only memory (ROM) 110 and random access memory (RAM) 112.A basic input/output system 114 (BIOS), containing the basic routinesthat help to transfer information between elements within the personalcomputer 100, such as during start-up, is stored in ROM 110. Thepersonal computer 100 further includes a hard disk drive 116 for readingfrom and writing to a hard disk, not shown, a magnetic disk drive 118for reading from or writing to a removable magnetic disk 120, and anoptical disk drive 122 for reading from or writing to a removableoptical disk 124 such as a CD ROM or other optical media. The hard diskdrive 116, magnetic disk drive 128, and optical disk drive 122 areconnected to the system bus 106 by a hard disk drive interface 126, amagnetic disk drive interface 128, and an optical drive interface 130,respectively. The drives and their associated computer-readable mediaprovide nonvolatile storage of computer readable instructions, datastructures, program modules and other data for the personal computer100. Although the exemplary environment described herein employs a harddisk, a removable magnetic disk 120 and a removable optical disk 124, itshould be appreciated by those skilled in the art that other types ofcomputer readable media which can store data that is accessible by acomputer, such as magnetic cassettes, flash memory cards, digital videodisks, Bernoulli cartridges, random access memories (RAMs), read onlymemories (ROM), and the like, may also be used in the exemplaryoperating environment.

A number of program modules may be stored on the hard disk, magneticdisk 120, optical disk 124, ROM 110 or RAM 112, including an operatingsystem 132, one or more application programs 134, other program modules136, and program data 138. A user may enter commands and informationinto the personal computer 100 through input devices such as a keyboard140 and pointing device 142. Other input devices (not shown) may includea microphone, joystick, game pad, satellite dish, scanner, or the like.These and other input devices are often connected to the processing unit102 through a serial port interface 144 that is coupled to the systembus 106, but may be connected by other interfaces, such as a parallelport, game port or a universal serial bus (USB). A monitor 146 or othertype of display device is also connected to the system bus 106 via aninterface, such as a video adapter 148. In addition to the monitor 146,personal computers typically include other peripheral output devices(not shown), such as speakers and printers.

The personal computer 100 may operate in a networked environment usinglogical connections to one or more remote computers, such as a remotecomputer 150. The remote computer 150 may be another personal computer,a server, a router, a network PC, a peer device or other common networknode, and typically includes many or all of the elements described aboverelative to the personal computer 100, although only a memory storagedevice 152 has been illustrated in FIG. 1. The logical connectionsdepicted in FIG. 1 include a local area network (LAN) 154 and a widearea network (WAN) 156. Such networking environments are commonplace inoffices, enterprise-wide computer networks, intranets and Internet.

When used in a LAN networking environment, the personal computer 100 isconnected to the local network 154 through a network interface oradapter 158. When used in a WAN networking environment, the personalcomputer 100 typically includes a modem 160 or other means forestablishing communications over the wide area network 156, such as theInternet. The modem 160, which may be internal or external, is connectedto the system bus 106 via the serial port interface 144. In a networkedenvironment, program modules depicted relative to the personal computer100, or portions thereof, may be stored in the remote memory storagedevice. It will be appreciated that the network connections shown areexemplary and other means of establishing a communications link betweenthe computers may be used.

General Overview

FIG. 2 is a general block diagram illustrating a system and method forautomatically providing dynamically generated completion information forfacilitating user input of email addresses or contact information inaccordance with the present invention. First, a program informationmodule (PIM) 200 scans sources of electronic data containing emailaddresses and contact information. These sources preferably include suchdata as an electronic mail store 210, other sources of electronic mail220, and other electronic files, such as for example, word processor andspreadsheet files 230. Collectively, these sources of electronic datamake up a “data store” from which email addresses and contactinformation is retrieved. The electronic mail store 210 typicallycontains received email 240, sent email 250, and other contactinformation 260. The PIM scans the data store from which it extractsemail addresses and contact information that is weighted and used toinitially populate a dynamic resolution list 270. Data from theresolution list is then made available to the user via a user interface280. This process is preferably repeated to rebuild or restore theresolution list after a “crash” or other unexpected event occurs thatcauses the resolution list to be lost. Once the initial resolution listis initially populated, it is preferably dynamically updated with newemail address and contact information as that information enters thedata store.

FIG. 3 is a flowchart illustrating the general operational features ofthe present invention. First, the invention preferably initiallypopulates the resolution list with email and contact entries in the datastore 300. The invention then analyzes the characteristics of entries inthe data store 310. Once the entries have been analyzed, the mostrecently used entries of the data store are determined 320. The entriesare then used to selectively populate a temporary storage area, i.e. theresolution list, based on predetermined population rules 330. Access isthen provided to the storage area via a user interface for facilitatinggeneration of dynamic completion information for an email or contactentry by the user 340.

Component Overview

The “data store” which is accessed by the PIM for extracting emailaddresses and contact information preferably includes multiple sourcesof electronic data. These sources include, for example, previously sentor received email, email addresses and contacts that existed withinother or older software versions that were subsequently upgraded and/orupdated with software embodying the current invention, other databasemail store listings located on local or public servers, contact listingsfrom current and/or previous contact databases or address books, anddata embedded within other types of electronic files such as, forexample, word processor, spreadsheet, database, or presentation files.

For example, a user typically has “inbox” and “sent items” folders, orthe equivalent, which contain received and sent messages, respectively.Additional messages may be stored or archived in other “folders” or“directories.” Email messages existing within this portion of the datastore preferably contain useful data elements within a header of thoseemail messages. This header preferably contains data elements such asthe email address the message is being sent to, or the email address themessage was received from, a “distribution list” of multiple addressesif the message was sent to more than one email address, and emailaddresses on the CC and BCC lines. Further, the header preferablycontains the date that the message was either sent or received. Inaddition, email addresses and contact information are often associatedwith “friendly names.” For example, if the email address is“joes554@hotmail.com,” the friendly name associated with this emailaddress may be “Joe Smith”. The PIM can extract all of this information,among other elements, for inclusion in the resolution list.

The PIM preferably acts in the background to initially scan items withinthe data store for information extraction. In other words, mining of thedata store for information extraction preferably occurs as a backgroundprocess that is transparent to the user, and preferably in such a manneras avoid noticeably affecting other processes being employed by theuser. Extracted information is formatted and weighted before entry inthe resolution list. Details of how entries are formatted and weightedbefore inclusion in the resolution list are discussed below.

The data extracted from the data store is preferably formatted andweighted to produce “entries” for initially populating the resolutionlist. Entries are preferably added to the resolution list based on a setof rules that considers parameters such as, for example, the entry'sweight, frequency of use, whether the user has chosen to block incomingmessages from certain email addresses or internet domains (i.e. “junkemail filtering”), and whether the entry already exists in the user'saddress book or contact database. One example of a set of rules forpopulating the resolution list is illustrated in the flowcharts of FIG.4A through FIG. 4D. These rules are discussed below in detail.

The resolution list contains multiple entries, each entry preferablycontaining data elements such as, for example, email address or contactinformation, friendly name (if known), the frequency of mail sent toand/or received from the address or contact, the date the address waslast sent to the date the address was last received from, and theentry's weight. Other data elements may be included or excluded byextracting either more or less information from items within the datastore.

Because items within the data store can encompass many various filetypes and formats, these items may not always have every data elementthat may be desirable for inclusion in the resolution list. Therefore,the PIM is capable of operating with any combination or subset of thedesired data. For example, an item in the data store may simply containan email address or contact with no other associated information.However, as additional information is received from other items enteringthe data store, the properties of particular entries within theresolution list are preferably updated to include that information.

The email address or contact information typically contains an addressto which correspondence may be sent. For example, a typical emailaddress takes the form of “tom123@domainxyz.com.” As a user begins toenter the email address or contact, the PIM pulls the completioninformation from the resolution list to complete the user's entrywithout the need for the user to enter the entire email addressmanually.

A “friendly name” is used to associate an easily identifiable name withan email address. For example, “tom123@domainxyz.com” may be the emailaddress for “Thomas Jones.” The friendly name is often tied to the emailaddress in sent or received email, and thus may be easily extracted bythe PIM for inclusion in an entry in the resolution list. While the usermay not know or remember that Thomas' email address istom123@domainxyz.com, he will likely know who he wishes to correspondwith. Consequently, where a friendly name is associated with the emailaddress, as the user begins to enter that friendly name, the PIM pullsthe completion information from the resolution list to complete theuser's entry without the need for the user to enter any part of theactual email address.

The number of times that mail has been sent to and/or received from aparticular address or contact is preferably used in determining theweight assigned to an entry in the resolution list. Because theresolution list is dynamic, the weight assigned to an entry increasesdynamically as the number of times that entry is used increases.However, the weight is preferably also dependant upon other dataelements, such as, for example, the date the address was last sent to,and the date the address was last received from. Further, as time passeswithout an entry being used, the weight of that entry is preferablydecreased. Entries having a greater weight preferably have precedencewhen replacing entries in the resolution list, as is discussed below.

Component Details and Operation

FIGS. 4 a through 4 d are flowcharts that illustrate one possible set ofrules for populating the resolution list from items within the datastore. The size of the resolution list, i.e. how many entries may beheld in the list, is preferably constrained as to the maximum number ofentries that will ensure that the user does not notice a lag time whilethe software searches for probable matches in the resolution list.However, in one embodiment, the user may modify the size of theresolution list.

Pre-Population of the Resolution List

In initially building the resolution list, or restoring the resolutionlist following a “crash” or other unexpected event occurs that causesthe resolution list to be lost, addressing information from users' datastores and from data available after software upgrades or competitiveapplication conversions will be extracted and used to pre-populate theresolution list. If the number of entries in the resolution list reachesthe maximum allowed during the pre-population operation, entries havinggreater weights will replace those entries having lower weights,starting with the entry having the lowest weight. Consequently, if theitems within the data store contain insufficient data to completely fillthe resolution list, all of the available data will be added to theresolution list.

Because the user's address book and contact database is preferablyavailable to the PIM for generation of completion information, emailaddresses and contact information that is already stored in the user'scontact database or address book need not be added to the resolutionlist.

Repeated instances of identical email addresses or contact informationwithin a single item in the data store preferably do not have amultiplier effect on the weight of an entry in the resolution list.Further, multiple duplicate entries are preferably not added to theresolution list in this case. For example, if “joe@ips.com” is enteredmore than once in the “To” field of a message, or in more than one placein the message, the effect on the weight of the entry will be the sameas if it was entered only once on the “To” line. However, repeatedinstances of the email address or contact information within multipleitems in the data store preferably serves to increase the weight of theassociated entry in the resolution list.

In addition, single items within the data store may contain datasufficient for multiple unique entries in the resolution list. Forexample, the To, CC, and BCC fields of a sent or received email messagewithin the data store may provide multiple unique email addresses orcontact information. Further, distribution lists in an email message arepreferably added as multiple separate entries to the resolution list inthe same manner as if each addressee in the distribution list were in aseparate email message.

Updating the Contents of the Resolution List

Following the initial pre-population of the resolution list, entries inthe list are preferably inserted, removed, and/or updated according to aset of rules similar to those for pre-population of the list. Each timethe PIM is started after the initial pre-population of the resolutionlist, the PIM preferably scans the data store and updates existingentries in the resolution list. This is preferably done as a backgroundprocess, but may also be done as a foreground process if user inputrequires access to the resolution list before it has finished beingupdated. In addition, as the user enters new email addresses or contactinformation in an email message, or as new email messages having emailaddresses or contact information are received, that information is alsoused by the PIM to dynamically update the resolution list. Further, newentries are preferably added to the resolution list in accordance withthe applicable rules as discussed below.

Preferably, an email address or contact should be used in a send orreceive operation before it is added to the resolution list. Forexample, if a message note is opened and addressed to“billc@whitehouse.gov,” the address is resolved, but if the message isthen closed without being saved, the resolution list is unaffected.Similarly, if email messages are waiting in the outbox when an SMTPserver goes down or when the user is working offline, the emailaddresses or contacts in the effected messages are preferably not addedto the resolution list because those messages were not successfullysent. In other words, entries are preferably added to the resolutionlist upon confirmation of send (such as by either SMTP or DAV server),or by saving the message as a draft.

The properties of email addresses and contacts that already exist in theresolution list are preferably updated as new information becomesavailable in the data store; otherwise, they are added as a new entry tothe resolution list. Consequently, each time an email address or contactfrom the list is used, its properties are preferably updated. Asdiscussed previously, these properties include such elements as emailaddress or contact information, friendly name, the frequency of mailsent to and/or received from the address or contact, the date theaddress was last sent to, the date the address was last received from,and the entry's weight. Matching within the resolution list ispreferably done by email address. As a result, when a match is found inthe resolution list (by email address), data elements in the entry, suchas the friendly name will be updated with however those elements are setin the new data item.

As with pre-population of the resolution list, when the resolution listis “full,” new entries extracted from the data store may be added to theresolution list by replacing existing non-duplicate entries with lowerweight values, starting with the item with the lowest weight value.Weight may be calculated using many different parameters, however, theparameters which are preferably used to calculate weight include thenumber of times that the email address or contact has been used foreither sending or receiving (N_(u)), the number of days since theaddress was last used in a send operation (N_(s)), and the number ofdays since the address was used for a receive operation (N_(r)). Oneexample of an equation that uses these parameters to calculate theweight of individual entries in the resolution list is:${Weight} = {\frac{N_{u}^{2}}{\left( {\left( {1 + N_{s}} \right) + \left( {2*N_{r}} \right)} \right)}.}$As discussed previously, the weight of an entry in the resolution listis dynamic, and is preferably updated both as new data becomes availableand as time passes.

In the case where an item within the data store contains multipleentries (From, To, CC, BCC, “distribution list,” etc. . . . ), theentries are added as a “batch operation.” Specifically, the criteriaused to determine whether or not an entry should be added to theresolution list (and therefore bump entries out of the resolution listif it is full) preferably remains intact until the batch operation isdone. In other words, the criterion is preferably reset after eachmessage is sent or received, or after an item is added to the datastore, not simply after each entry is added to the resolution list.Consequently, the weights of entries in the resolution list arepreferably not updated until the batch operation is complete. Therefore,it is possible that entries added to a full resolution list in a batchoperation may be replaced with other entries from the same batchoperation having an equal or greater weight before the batch operationis complete. The determining factor is the weight assigned to entriesalready existing within the resolution list, and the weight of theentries being added to the list.

In the case where multiple entries within the resolution list have thesame, yet lowest, weight value as a new potential entry, the new entrywill be added and the item replaced will be determined arbitrarily fromwithin a set of entries having the same weight value. This rulepreferably applies to cases of batch entries as well as single entries.

Because junk email is becoming a common concern, the resolution list ofthe present invention preferably avoids processing junk email forinclusion in the list. This may be implemented in various ways, such as,for example, allowing the user to block incoming messages from certainemail addresses or Internet domains, providing a junk email folder, orit's equivalent, into which junk email may be placed, or by removingentries associated with deleted items from the resolution list. Blockedmessages, or messages in the junk email folder are preferably notprocessed for inclusion in the resolution list. If a user chooses toblock email from a certain email address or domain after previouslyhaving allowed receipt of such messages, any entries in the resolutionlist associated with the blocked material are preferably removed fromthe list.

The user's address book and/or contact database is preferably availableto the PIM for generation of completion information. Consequently, emailaddress and contact information that is added to the address book and/orcontact database need not also be located in the resolution list.Therefore, when an entry in the address book or contact database issaved, any matches on email address found in the resolution list arepreferably removed from the list. Further, the resolution list ispreferably unaffected by changes (other than new email addresses orcontacts) in the address book or contact database. For example, if theproperties of an email address or contact are changed in the addressbook or contact database, or an email address or contact is deleted fromthe address book or contact database, the resolution list is unchanged.However, once an email address or contact has been deleted from theaddress book or contact database, it may be subsequently added to theresolution list based on subsequent usage or if it is supported by datawithin the data store.

While the maximum size of the resolution list is preferably constrainedto ensure that the user does not notice a lag time while the softwaresearches for probable matches in the resolution list, the initial ordefault value may be modified by the user. The user, through a userinterface, may increase or decrease the size of the resolution list tosuit his needs. Further, if the user desires to disable the resolutionlist, the user may either set the size of the list to zero, or simplydisable the list from the user interface.

While the resolution list is preferably stored in RAM to enable rapidaccess, it is also preferably cached to disk so that the list willremain accessible both between instances of the application andoperating system reboots. If the user chooses to disable the resolutionlist, the list is preferably cached to disk, but is preferably no longeraccessible for generation of completion information, and is preferablynot updated while disabled. However, if the user then chooses at a latertime to re-enable the resolution list, the prior list is preferably readfrom disk. The PIM then updates this list based on the current contentsof the data store as discussed above. Further, in the event that theresolution list becomes corrupted, or has been flushed by setting themaximum number of entries to zero, the list is preferably re-populatedas in the pre-population case discussed above.

The rules discussed above for pre-population and updating of theresolution list may be summarized by the flowcharts of FIG. 4A throughFIG. 4D, which illustrate one possible set of rules for implementing andmaintaining a resolution list in accordance with the present invention.

Specifically, FIG. 4A is a general flowchart illustrating the initialpre-population, or recreation of the resolution list. The procedure isstarted by determining the number of entries to be included in theresolution list (Box 400). Next, a determination is made as to whethermore entries are needed to complete the list (Box 402). If more entriesare needed, the data for the entries is extracted from the data store(s)(Box 404). Next, a determination is made as to whether the dataextracted from the data store already exists in the user's address book,or is blocked (i.e. junk email) (Box 406). If the data is blocked, it issimply ignored (Box 408). If the data is not blocked, it is added to theresolution list (Box 410). These steps are repeated until the resolutionlist is full, or until all information in the data store(s) has beenscanned, at which point, the entries which have been added to theresolution list are weighted (Box 412). Box 412 is further detailed inthe flowchart of FIG. 4B.

Each entry in the resolution list is preferably individually weighted asillustrated in FIG. 4B (Box 412). First, a determination is made as towhether the address in an entry has been sent to or received from (Box414). If the address has been used to send or receive, a determinationof send/receive usage (N_(u)), is made (Box 416). Next, a determinationof the send frequency (N_(s)) (Box 418), and the receive frequency(N_(r)) (Box 420) is made. These values are then used to calculate andassign a weight to each entry (Box 422). This weighting process isrepeated for each entry in the resolution list.

Following the initial pre-population and weighting of the resolutionlist, entries in the resolution list are updated as new informationenters the data store (Box 430). FIG. 4C is a general flowchart thatfurther details Box 430 of FIG. 4A, by illustrating one method forupdating entries in the resolution list. Each data element entering thedata store(s) (Box 432) is examined to see if the email address orcontact information already exists in the resolution list (Box 434). Ifthe address or contact information already exists in the resolutionlist, the values for send/receive usage (N_(u)), send frequency (N_(s)),and receive frequency (N_(r)) are updated (Box 436). Further, otherproperties of the entry, such as the friendly name, are also updated(Box 438). The weight of the entry is then calculated (Box 422) whetheror not contact information already existed in the resolution list. Oncethe weight is calculated, a determination is made as to whether theentry should be added to, kept in, or deleted from the resolution list(Box 440). These steps are preferably repeated until all new dataentering the data store has been examined (Box 442).

FIG. 4D is a general flowchart illustrating one method for determiningwhether the entry should be added to, kept in, or deleted from theresolution list. Specifically, a determination is made as to theallowable number of entries in the resolution list (Box 446). Next, adetermination is made as to the minimum weighting value for entries inthe resolution list (Box 448). The weight of a new potential entry iscompared to the minimum weight (Box 450). If the weight of the newcandidate is greater than the entry in the resolution list having thelowest weight, the new candidate is added to the resolution list (Box452). If the maximum allowable number of entries in the resolution listhas been exceeded, the entry having the lowest weight is removed fromthe resolution list (Box 454).

User Interface Integration with Resolution List

One example of a user interface that may be implemented with a systemand method in accordance with the present invention is illustrated as ablock diagram in FIG. 5. The user interface 500 for the resolution listpreferably provides a data entry area 510 wherein the user can manuallyenter the desired email address or contact. As described above,completion information is automatically generated from both theresolution list and the user's address book as the user begins to enterthe address or contact. This information is provided to the user via anaddress/contact resolution pop-up 520. The pop-up 520 preferablydisplays resolved email addresses or contacts 530 that are possiblematches to the users partial input. These resolved addresses or contactsare displayed in order beginning with the entry having the highestweight. In other words, the entry most likely to match the user'sdesired input, based on the criteria described above, is displayedfirst, with other possible matches displayed in descending order oflikelihood of matching the user's partial input.

The address/contact resolution pop-up 520 also preferably provides anoption via a “push-button” or the equivalent for the user to select thedesired entry 540 from the resolution list for addressing the email withauto-completion information as described above. Further, because entriesare displayed from highest to lowest weight 530, the user may browse thecontents of the resolution list. While browsing the resolution list, theuser interface preferably allows the user to selectively add entries 550from the list to his or her address book or contact database. Asdiscussed previously, entries added to the address book or contactdatabase are preferably removed from the resolution list.

Further, because it is considered beneficial to populate the user'saddress book or contact database with frequently used email addressesand contacts, the PIM, through the user interface, may automaticallysuggest that the user add certain resolution list entries to the addressbook or contact database. This feature is preferably based on an entry'sweight and frequency of use.

FIG. 6 is a sample user interface for an email client utilizing thepresent invention. The pop-up user interface 520 can be implemented asshown in FIG. 6. The user interface of FIG. 6 allows efficient emailaddressing by minimizing users' keystrokes and mouse clicks. Inparticular, as shown in FIG. 6, the user interface 600 can include apop-up user interface that automatically appears near a data entry area612 when the user initiates data entry in the area 612.

As discussed above, a list of the most recently used (MRU) sent to andreceived from addresses can be used to populate the pop-up menu 610. TheMRU list can be integrated with multiple addressing sources. An MRU thatis populated with sent to and received from addresses helps novice usersthat are unaware or unfamiliar with address books. These novice usersoften complete email addresses to a particular user by finding an oldermessage that was either sent to or received from the particular user.Each address can be assigned a weighting value determined by 1) whetherthe address was sent to (higher weighting) or received from (lowerweighting); 2) the number of times the message has been sent to/receivedfrom; and 3) the frequency of sending/receiving (i.e. number of messagesdivided by the time that has passed between the first message and thecurrent time); Addresses with weights below a certain threshold valuecan be dropped off the list. Also, addresses with high weights caninitiate a prompt to the user to suggest adding to the contact to theuser's address book.

For illustrative purposes, as a user types characters into an addressingfield 612, a pop-up menu 610 appears directly below the cursor 614, asshown in FIG. 6. The pop-up menu 610 is preferably vertically alignedwith the left edge of the data entry area 612. The popup menu 610 ispopulated with entries as discussed above and in accordance with thepresent invention, such as entries whose first name, last name,nickname, or email address starts with the same string that the usertypes in the data entry area 612. The string matching is preferably notcharacter case sensitive. As the user types, the pop-up menu 610 isdynamically updated so that it contains only those items which start andmatch with the currently entered string. If the user deletes characters,the pop-up menu 610 is similarly updated and possibly expanded.

In the example of FIG. 6, as the user has types “dav”, the popup window610 is populated with entries in accordance with the present invention.The pop-up menu 610 preferably has three columns. The columns containdifferent data depending on which portion of data from the contactmatches the typed string. It should be noted that that groups can bematched against the name of the group. The different types of data areoutlined in TABLE 1 below. TABLE 1 Autofill by: 1^(st) Column 2^(nd)Column Example First name <first><space> <greater than> Bob Jones <last><email address> <bj@isp.com> <less than> Last name <last><comma><greater than> Jones, Bob <space><first> <email address> <bj@isp.com><less than> Nickname <nickname><space> <greater than> BJ (Bob Jones)<open <email address> <bj@isp.com> paren><first> <less than><space><last> <close paren> Email address <email address> <first><space>bj@isp.com Bob Jones <last> Group name <group name> <open Humor List (7paren><number of recipients) contacts in group> <space>recipients <closeparen> Mailing List <mailing list <greater than> MacOE-Talk <macoe-Manager item name> <list address> talk@lists.boingo.com> <less than>

The last column displays a sub-menu arrow 616 if a contact 618 has morethan one email address. The arrow can be selected by the user to producea sub-pop-up menu 620 with extended entries 622 related to the contact618 or all of the addresses associated with the contact. However, if theentry matches an email address, a sub-pop-up menu preferably does notappear even if the contact has multiple addresses. The sub-pop-up menu620 is shown by default when the selection is on an item with a submenu.However, an item in the sub-pop-up menu 620 is not selected until a userexplicitly presses the right arrow button or moves the mouse over anitem. Once the keyboard is used to move the selection, the position ofthe mouse should be ignored until it is moved past a threshold value(such as 5 pixels). The sub-pop-up menu is displayed so that the secondaddress is aligned with the main menu item as shown in FIG. 6. Thisminimizes the number of keystrokes for a user to select a non-defaultaddress.

Each contact preferably appears only once in the pop-up menu 610.However, a particular contact may appear in the list multiple times ifmultiple matches of the contact exists (i.e. David Davidson<davidd@isp.com>). If this occurs, then the following precedence ispreferably used: first name, last name, nickname, email address. Theprecedence of the first two items can be switched by the preference forwhether to list contacts in the address book by first name or last name.If the entry no longer matches a higher up precedence as a usercontinues to type to constrain the name matches, then the entry willreappear in the list at the next lower precedence that matches. Forexample, as the user enter data from “david” to “davids”, the entrywould change from “David Davidson <davidd@isp.com>” to “Davidson, David<davidd@isp.com>”.

If there are two or more contacts with the exact same display name(first & nickname & last), another identifier, such as company name, canbe appended in parentheses to the display name to help users distinguishamong contacts. If one of these contacts is selected, the display namein the addressing header reverts to the standard first & last; nicknameand the additional identifier is omitted.

Certain keystrokes can have new functionality when the user is in themiddle of a type-ahead, as illustrated in TABLE 2 below: TABLE 2 Returnor In auto-complete mode: Enter the currently selected auto- Enterfilled contact as a verified address, change proxy icon to “contact”,and place the cursor on the next recipient line. When a recipient isselected: Close the addressing input popup and place the focus in theSubject field with the entire contents of the Subject field selected. Onan empty recipient line: Close the addressing input popup and place thefocus in the Subject field with the entire contents of the Subject fieldselected. Tab In auto-complete mode: Enter the currently selected auto-filled contact as a verified address, change proxy icon to “contact”,and place the cursor on the next recipient line. When a recipient isselected: Select the next recipient in the list, or move to a new emptyrecipient line if the currently selected one is last. On an emptyrecipient line: Close the addressing input popup and place the focus inthe Subject field with the entire contents of the Subject fieldselected. Shift- In auto-complete mode: Auto-fill up to and includingthe Space first space in the selected contact (i.e. “dav” becomes “David”) and remain in auto-complete mode. Arrow Cycle up/down throughaddresses in the list that match keys the current string. Move focusbetween the main menu and the sub-menu (if one exists). Up and downarrow keys in the submenu will cycle (i.e. down arrow on the last itemwill move selection to the first item). Arrow key navigation overridesthe position of the mouse. Note: with regard to insertion point and menuselection, the arrow keys preferably do not control the insertion pointduring type-ahead. Using the Command key modifier in conjunction withthe arrow keys will move the insertion point. Delete Delete the lastcharacter typed and update the current auto-completed address list asappropriate. Escape In auto-complete mode: Hide the auto-complete pop-upand do not bring it back up again on this text string for the remainderof the time that the user is typing this string (that is, until the usertypes Return and accepts the text as an object. If the user then clicksinto the object and types more, the pop-up can come back up). Otherwise:Close the addressing popup. Control- Bring up an auto-complete pop-upfiltered on the word or Return prefix to the left of the insertionpoint. This can be used to bring up the pop-up after it has beendismissed with the Escape key. . (period) In the context of a newsgroup,this is similar to the Tab key. For example, if I type re.hu.fu I shouldget rec.humor.funny

The foregoing description of the invention has been presented for thepurposes of illustration and description. It is not intended to beexhaustive or to limit the invention to the precise form disclosed. Manymodifications and variations are possible in light of the aboveteaching. It is intended that the scope of the invention be limited notby this detailed description, but rather by the claims appended hereto.

1-53. (canceled)
 54. A computer readable medium having computerexecutable instructions for providing an automatic electronic contactresolution list, said computer executable instructions comprising:automatically extracting contact information from any of a plurality offile types included in a data store, said data store including at leastone of word processor files, spreadsheet files, and presentation files;wherein extracting the contact information includes automaticallyexamining the complete contents of one or more of the files in the datastore and extracting any contact information located within thosecontents; maintaining a list of at least one contact entry derived fromthe contact information extracted from the data store; automaticallycomputing a weight for each entry in the list; tracking contactinformation associated with the contact entry; automatically resolvingcontact entries in real time by dynamically providing specific contactentries from the maintained list based on the weight of each entry inthe list; wherein new entries are added to the list as new informationenters the data store; wherein entries are removed from the list andreplaced with new entries when the list is full; and wherein entries areassigned relative weights, and wherein new entries having weights thatare at least equal to the weights of existing entries in the list areadded to the list to replace the existing entries.
 55. The computerreadable medium of claim 54 wherein the data store includes sent andreceived email.
 56. The computer readable medium of claim 54 wherein thedata store includes database files.
 57. The computer readable medium ofclaim 54 wherein automatically resolving contact entries comprisesproviding a most probable match to an input.
 58. The computer readablemedium of claim 54 wherein automatically resolving contact entriescomprises providing a most recently used match to an input.
 59. Thecomputer readable medium of claim 54 wherein automatically resolvingcontact entries comprises providing the entry having the greatest weightwhere one or more entries match an input.
 60. The computer readablemedium of claim 54 wherein the contact information of the entriesincludes a plurality of information elements including any one or moreof: an email address; a friendly name; a number of times that the entryhas been used; a date the email address was last sent to; a date theemail address was last received from; and a weight.
 61. A method forproviding an automatic electronic contact resolution list comprisingsteps for: automatically extracting contact information from any of aplurality of file types included in a data store, said data storeincluding at least one of word processor files, spreadsheet files, andpresentation files; wherein extracting the contact information includesautomatically examining the complete contents of one or more of thefiles in the data store and extracting any contact information locatedwithin those contents; maintaining a list of at least one contact entryderived from the contact information extracted from the data store;automatically computing a weight for each entry in the list; trackingcontact information associated with the contact entry; automaticallyresolving contact entries in real time by dynamically providing specificcontact entries from the maintained list based on the weight of eachentry in the list; wherein new entries are added to the list as newinformation enters the data store; wherein entries are removed from thelist and replaced with new entries when the list is full; and whereinentries are assigned relative weights, and wherein new entries havingweights that are at least equal to the weights of existing entries inthe list are added to the list to replace the existing entries.
 62. Themethod of claim 61 further comprising steps for constraining the size ofthe list to improve a performance of automatically resolving contactentries.
 63. The method of claim 61 further comprising steps forspecifying the size of the list via a user interface.
 64. The method ofclaim 61 further comprising steps for disabling the list via a userinterface.
 65. The method of claim 61 further comprising steps forrandomly choosing an entry in the list having the lowest weight andreplacing the randomly chosen entry with a new entry if the lowestweight of entries in the list is equal to the weight of the new entryand that weight is shared by at least two entries in the list.
 66. Themethod of claim 61 further comprising steps for adding new entries tothe list after those entries are first used.
 67. The method of claim 61further comprising steps for using an existing contact database with themaintained list for automatically resolving contact entries.
 68. Asystem for providing an automatic electronic contact resolution listcomprising using a computing device to: automatically extract contactinformation from any of a plurality of file types included in a datastore, said data store including at least one of word processor files,spreadsheet files, and presentation files; wherein extracting thecontact information includes automatically examining the completecontents of one or more of the files in the data store and extractingany contact information located within those contents; maintain a listof at least one contact entry derived from the contact informationextracted from the data store; automatically compute a weight for eachentry in the list; track contact information associated with the contactentry; automatically resolve contact entries in real time by dynamicallyproviding specific contact entries from the maintained list based on theweight of each entry in the list; wherein new entries are added to thelist as new information enters the data store; wherein entries areremoved from the list and replaced with new entries when the list isfull; and wherein entries are assigned relative weights, and wherein newentries having weights that are at least equal to the weights ofexisting entries in the list are added to the list to replace theexisting entries.
 69. The system of claim 68 wherein entries are removedfrom the list when matching entries are added to a contact database. 70.The system of claim 68 wherein the automatically resolved contact entryis selectable by a user via a user interface.
 71. The system of claim 68wherein items entering the data store are automatically scanned forcontact information as the items enter the data store.
 72. The system ofclaim 68 wherein entries in the list are automatically updated as newinformation matching the entries enter the data store.
 73. The system ofclaim 68 wherein particular items within the data store are excludedfrom tracking.